v2/pkg/engine/datasource/graphql_datasource/graphql_datasource_federation_test.go (1)

20223-20245: Test narrative is stale and contradicts the actual scenario.

These comments describe NodeB/Pool/Pool1/sharedField and second-subgraph ownership of uniqueField, but the test actually models NodeA -> Detail and resolves uniqueField from the first subgraph. Please align comments with the implemented schema and expected fetches.

♻️ Suggested comment cleanup

-		// Tests a scenario where the planner must navigate through multiple layers of
-		// abstract types with `@external` fields to reach an entity whose fields are
-		// split across subgraphs. Mirrors a real-world pattern where:
-		//
-		//   - Node (interface) is implemented by NodeA and NodeB
-		//   - NodeA/NodeB declare pool: Pool! as `@external` in the first subgraph
-		//     (to satisfy the Node interface), but Pool is truly owned by the second subgraph
-		//   - Pool (interface) is implemented by Pool1
-		//   - Pool1.detail: Detail! is `@external` in the first subgraph, owned by the second
-		//   - Detail is an entity with fields split across subgraphs:
-		//       uniqueField → second subgraph only
-		//       sharedField → first subgraph only
-		//
-		// Expected execution (zigzag: first → second → first):
-		//   Fetch 0: first  subgraph — root nodes query, returns NodeA keys
-		//   Fetch 1: second subgraph — entity-resolve NodeA, traverse pool → Pool1 → detail,
-		//                              inline Detail.uniqueField (owned by second subgraph)
-		//   Fetch 2: first  subgraph — entity-resolve Detail to get sharedField
-		//
-		// Planner confusion: Pool1 appears as an entity in the first subgraph with
-		// detail `@external`. The planner may incorrectly try to resolve detail through
-		// the first subgraph's Pool1 entity, not realising it must go via the second
-		// subgraph's NodeA entity resolution first.
+		// Regression: ensure parent selection does not stop at an external interface field.
+		// Scenario:
+		//   - `Query.nodes` is fetched from first subgraph.
+		//   - `NodeA.detail` is external in first subgraph and resolved via second subgraph.
+		//   - `Detail.uniqueField` is then resolved back in first subgraph via entity jump.
+		//
+		// Expected execution: first -> second -> first.
@@
-			// Second subgraph: owns pool on NodeA/NodeB, owns detail on Pool1,
-			// owns Detail.uniqueField. Detail.sharedField lives only in first subgraph.
+			// Second subgraph: resolves NodeA.detail and returns Detail keys.
@@
-								// Fetch 1: entity-resolve NodeA from second subgraph.
-								// Second subgraph owns pool (non-external on NodeA), Pool1.detail, and Detail.uniqueField,
-								// so all three can be resolved inline without additional entity fetches.
+								// Fetch 1: entity-resolve NodeA in second subgraph and return Detail.id.
@@
-								// Fetch 2: entity-resolve Detail from first subgraph to get sharedField.
-								// This is the jump back — first subgraph is the only owner of Detail.sharedField.
+								// Fetch 2: entity-resolve Detail in first subgraph to get uniqueField.

Also applies to: 20359-20360, 20475-20477, 20516-20517

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@v2/pkg/engine/datasource/graphql_datasource/graphql_datasource_federation_test.go`
around lines 20223 - 20245, The test comments for the federation scenario are
stale and misdescribe the implemented schema and expected fetch sequence; update
the narrative comments that mention NodeB/Pool/Pool1/sharedField and the
ownership of uniqueField so they accurately reflect the actual test
implementation (which models NodeA -> Detail and resolves uniqueField from the
first subgraph), and adjust the listed expected execution steps to match the
real fetch order and ownership (references: Node, NodeA, NodeB, Pool, Pool1,
Detail, uniqueField, sharedField and the “zigzag” fetch sequence). Ensure you
update all occurrences noted (around the blocks near the ones flagged: the
current comment block and the later blocks at the same pattern) so comments
align with the schema and expected fetches.